It is assumed that in the future almost all fixed and mobile communications networks will be based on Internet technology. Especially, services combining several communication types and modes will lead the way in future networks. Voice itself will be just one, although important, piece in the whole communication architecture.
The Session Initiation Protocol (SIP) as defined in the Internet Engineering Task Force (IETF) specification RFC 3261, provides an emerging standard for setting up multimedia sessions on the Internet. Its basic capabilities are setup modification and tear down of any communication session, so it is a signaling protocol. SIP also provides personal mobility, meaning that a consumer is reachable via a single address regardless of its current point of attachment to the network.
In order to support multimedia services, seamless mobility and efficient multiparty conferencing, the IP layer needs to be enhanced. Mobile IP allows terminals to move freely between different mobile networks. SIP is used to establish, modify and terminate sessions. It provides personal mobility by allowing a user to dynamically register to the network with his communication address, i.e. SIP URI (Uniform Resource Indicator). A session is usually a number of Real-time Transport Protocol (RTP) streams to be exchanged. Normally, a session is a combination of speech, audio and video streams, but it may also contain shared applications. A basic SIP network is composed of four types of elements i.e. User Agents (UA), Proxy Servers, Redirect Servers and Registrar Servers. User Agents typically reside in endpoints such as IP phones, personal computers or mobile devices. They initiate requests and provide responses. Usually, UAs also have an interface to media handling and to the actual application software providing the user interface. Proxy servers are intermediaries, which receive and forward requests providing them with, e.g., routing or other services. Redirect servers simply respond to a request by asking its originator to redirect it to a new address. Registrar servers keep track on the actual points of contact of the consumers by accepting registrations from the UAs. Registrar servers and the SIP registration procedure in general provide user mobility as the consumer is able to be reachable from any location via a single address. In this sense, they resemble Home Location Register (HLR) functionality in the Global System for Mobile communications (GSM) networks. Each consumer is part of a domain and each domain runs at least one registrar server, which knows the location of its consumers if the are registered.
SIP uses an address format common to Internet Mail, i.e. “user@domain”. The domain part is used to find the correct domain for the consumer and the user part is used to distinguish between individual consumers within a domain. SIP includes request and response messages comprising header fields, e.g. for defining where the request is to be sent next, the recipient address, the sender address etc. Furthermore, a SIP message may contain a payload portion for transmitting subscriber or service specific information.
It is noted that RTP streams do not follow the same path as the SIP message did, but flow directly between the concerned devices. It is thus possible to send the subsequent SIP requests directly between the UAs. In IMS, subsequent SIP messages follow the path recorded into the Record-Route header of the initial request, while interrogating network nodes may drop themselves out and other network elements stay on path. On the other hand, proxy servers in the middle may ask to remain on the signaling path for the duration of the call. This might be useful if the proxy offers some services to the call.
Currently, the Third Generation Partnership Project (3GPP) is specifying IMS e.g. in its specification TS 23.228 as an access independent subsystem which can be used in connection with different networks. IMS uses SIP for session initiation. Basically IMS is just an instance of a SIP network. It has a number of proxies and a registrar. The UA is situated in the terminal device or user equipment (UE). When two devices establish a session they talk to each other via Call State Control Function or Call Session Control Function (CSCF) elements, while RTP media flows do not go via CSCFs but go directly between the devices. An Application Server (AS) is a SIP element dealing with services, such as advanced call control, presence or instant messaging. The AS may terminate sessions/transactions. The AS may also start sessions/transactions e.g. on behalf of a user or a service.
However, there may be situations where the AS does not know whether it should start originating or terminating services when it receives an incoming request message, e.g. an SIP INVITE message, or a serving CSCF (S-CSCF) does not know whether the incoming request message starts an originating or terminating session/transaction. Moreover, other information may be needed for load balancing within the network. Furthermore, for load sharing purposes in a connection processing server (CPS), especially in the S-CSCF and an interrogating CSCF (I-CSCF), it is important to provide a fast and easy algorithm to discover whether a received SIP request is the first in a SIP session or to which SIP session a received request or response belongs to. Currently, SIP does not provide such an efficient means. In order to identify a SIP dialog, i.e. call leg, identified by a combination of call identification, source and destination, a network element or UE has to compare the respective header fields of each SIP message and then to determine whether the call leg already exists. This implies heavy string comparisons and data base queries. A network element which maintains a high number of parallel call legs needs a lot of resources. Additionally, in case of a failure in a network element, information is required about existing sessions.